When a user access a network (e.g., logs onto an Internet service provider, turns on a wireless data device, etc.), the user is typically authenticated by the network. As part of the authentication process, a decision is made as to whether the user is allowed to access the network. Authentication and access control decisions are typically made by a dynamic host configuration protocol (DHCP) server or an authentication, authorization, and accounting (AAA) server such as a remote access dial in user service (RADIUS) or DIAMETER server (referred to generally herein as “access control servers”). If the user is permitted to access the network, a session is established for the user. The DHCP and AAA servers retain information regarding the user's current session.
Many applications require this session information in order to provide a service to a user. In current environments, the application must query the server which authenticated the user to obtain the needed session information. However, a single service provider, particularly a large geographically diverse service provider, may have numerous access control servers. Additionally, a service provider offering a variety of network types (e.g., wireline and wireless networks) may have multiple types of access control servers. In these complex service provider infrastructures, a user can come onto the network anywhere using any supported technology. An application may then need to query numerous servers using various message formats to find the server storing the session information for a particular user. The task of obtaining user session information is further complicated if the information is located in the network of another service provider. This situation typically occurs when a user roams into the service territory of another service provider. In roaming situations, an application in the user's home network may have no knowledge of a user's present location and therefore has no means to access session state information for that user.
One technique to obtain user session information is to write customized access modules for each type of access control server supported by a service provider. For example, an application may have a module for accessing a DHCP server, a module for accessing a RADIUS server, and a module for accessing a DIAMETER server. However, not all servers provide an interface for accessing session data. Thus, integrating these modules into an application may not be possible.
Another possible technique to obtain session information is to sniff packets from the network in real-time and trigger events based on the captured message. However, real-time sniffing of packets is complex and cannot provide non-message triggered events such as DHCP expiry events or missed RADIUS packets.
Therefore, what is needed is a system and method for providing centralized user session state information.
What is further needed is a common application programming interface (API) that can be used to access state information regardless of where and how a user accessed a network.
The present invention will now be described with reference to the accompanying drawings. In the drawings, like reference numbers can indicate identical or functionally similar elements. Additionally, the left-most digit(s) of a reference number may identify the drawing in which the reference number first appears.